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REMARKS 



The claims were rejected for double patenting. Applicant 
requests reconsideration. A terminal disclaimer is provided 
herewith. Claims 1-4, 6-18 were rejected as indefinite. 
Applicant requests reconsideration. The claims have been 
accordingly amended. 

The claims were amended in the prior response. Yet, in the 
current 04/09/07 office action, the examination refers to the 
claims without the prior amendments as though the amendments 
were not entered. Yet, there are other indications in the 
examination that the amendments were entered. As such, the 
prosecution record may now be confused. The claims are now 
restated, incorporating the prior amendments in clear form for 
the examiner's convenience. Applicant requests that the claims 
be entered as now presently stated. 

The present office action apparently did not examine the 
claims based upon the last amendments. On page 2 of the present 
office action, the recited claim 1 did not include the prior 
amendment. As such, applicant requests withdrawal of the final 
rejection, and requests reconsideration of the rejections. In 
the event that the examiner fails to enter the prior 
amendments, fails to enter the claims as now stated, fails to 
withdraw the final rejection, or fails to allow all of the 
claims, applicant requests a continued examination (RCE) of the 
above referenced original patent application. Applicant claims 
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priority to the original filing date. The Commissioner of 
Patents and Trademarks is authorized to charge Account No. 
010428 for any fees deemed due in connection with the filing of 
this document in the U.S. Patent and Trademark Office. 

The claims 1-4, 6, 8, 11, 12, and 14-17 were rejected as 
unpatentable over Jordan in view of Husak. The remaining Claims 
7, 10, and 13 were rejected as unpatentable over Jordan in view 
of Husak in view of Berstis, aka, Bertis. Applicant requests 
reconsideration. New claims 19 and 20 were added to recite that 
the association and broadcasting are used to form forwarding 
tables in the destination cache. 

The claims were rejected in part because the claims do not 
recite intended applications of the method steps for 
broadcasting associated routing information or recite arguments 
used in support of nonobviousness . These rejections are 
misplaced. The examiner states, on page 4, "In other words, the 
features upon which applicant relies, (as in applicant's 
arguments), are NOT recited in the rejected claims". This is a 
common perfunctory rejection often correctly used by examiners 
in anticipation rejections, but so often misplaced in the 
context of obviousness rejections. 

In claim 1, applicant claims a method of broadcasting, 
which method is executed solely at the proximal cache, AND NO 
MORE . This claim clearly sets the reference perspective as 
being the proximal cache at the proximal IPA. As such, a 
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potential infringer has notice that a proximal cache, so 
broadcasting, that is merely broadcasting without regard to 
creating a forwarding and routing table at a destination, 
perfects the method and is covered by the claim. With this 
broadcasting method, a routing and forwarding table at the 
destination can then be maintained at a distal cache. As such, 
applicant claims the method of broadcasting only in so far as 
the execution is exclusively performed at the proximal cache. 

There is no requirement that this claim also include 
language as to the intended uses or applications of this 
broadcasting method or requirement that this claim claims the 
benefits of this broadcasting method, as the examiner 
incorrectly suggests. An obviousness determination is focused 
upon whether or not the claimed combination is obvious. The 
determination of obviousness goes to both the solution as in 
part claimed in claim 1 and the problem solved as stated in 
argument. As to the solution in part, the combination of claim 
1 has not been rejected as anticipated, but rejected for 
obviousness. Anticipation can be determined by an element by 
element comparison. Applicant did not address an anticipation 
rejection, where elements must be recited in the claims and not 
found in a single prior art reference. If applicant had argued 
that claim 1 was not anticipated because the prior art does not 
teach a destination routing table in combination, then the 
examiner's assertion would have been correct, and the routing 
table should be recited in the claims. However, the rejection 
is one of obviousness that brings into consideration a whole 
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variety of related issues, such as, a long felt need without 
solution, and of course, the prior art problems solved. Surely, 
the examiner would not suggest that the claims must 
specifically recite the number of years that the prior art had 
such a long felt need, or necessarily recite the prior art 
problems solved, yet these two things do support a 
nonobviousness determination. Arguments that a claimed 
invention is not obvious need not be recited in the claims. It 
is simply enough that the combination not be anticipated, as 
indicated in the present record, and that the combination of 
claim 1, not be obvious. It is simply enough that the claimed 
broadcasting method steps in combination not be suggested, yet 
be useful. The reasons why a claim combination would not be 
obvious need not be recited in the claims. The examiner's basis 
for rejection because applicant's arguments are not found in 
the claims is without merit in the present obviousness 
determination context. 

The claims are patentably distinct as written. New claims 
19 and 20 add another step to claims 1 and 8 respectively of 
storing the association in the destination cache at the 
destination IPA, whereat a forwarding and routing table can be 
maintained. Hence, the use of the claimed combination of the 
broadcasting method of claim 1 then enables the creation of 
forwarding and routing tables at the destination IPA, and 
hence, enables the migration of routing information containing 
associations between URLs and source web cache IPAs 
subsequently stored as routing items in forwarding and routing 
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tables at destination IPAs. Significantly, the claim 1 steps 
provide a method of broadcasting routing information that can 
then be used by other distal caches for accomplishing the 
migration of forwarding and routing tables. Claim 1 claims a 
broadcasting method and not the creation of forwarding tables 
as now claimed in new claims 19 and 20. Surely, this 
unanticipated and unobvious broadcasting method is of some 
value . 

From a practical perspective, the examiner should realize 
that networks have distributive caches that can be manufactured 
by various entities. Claim 1 only covers a broadcasting cache, 
(i.e. the proximal cache), and hence, covers a necessary 
element to forwarding and routing table migration within an 
entire network. Claim 1 covers a necessary novel core of the 
invention because, without this broadcasting of routing 
information, a distal forwarding and routing table cannot be 
maintained by a proximal cache. Hence, claim 1 focuses on a 
core point of novelty while providing clear notice of the scope 
of the claim. Other systems do have caches, and do have 
forwarding tables, and do have routing tables, but do not 
broadcast tri-referenced associated routing information. Hence, 
the focus of claim 1 is directed to a necessary point of 
novelty. The threshold point of novelty is the broadcasting of 
tri-referenced associated routing information. This 
broadcasting does not include process steps occurring at the 
destination cache, so that one can determine from claim 1, 
which caches within a network are covered by claim 1, and which 
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ones are not. As such, the process steps of claim 1 are 
executed only at the proximal IPA, give clear notice as to what 
would infringe, and focuses the examination of this case. This 
claim 1 strategy provides clear notice, covers a necessary 
point of novelty, and focuses this examination on to that the 
point of novelty, which is the broadcasting method of claim 1. 

As such, the present invention of claim 1 serves to solve 
the problems of maintaining a network of cooperative caches 
through the migration of forwarding and routing tables by 
broadcasting tri-ref erenced associated routing information. The 
present invention solves the problem of routing table migration 
by broadcasting from a FIRST proximal cache to a SECOND 
destination cache at a destination IPA routing information that 
associates a URL-Id and a THIRD source IPA. These first, 
second, and third caches are tri-ref erenced in claim 1. This 
association is recited in claim 1. Claim 1 is particularly 
recited, novel, unobvious, and useful. 

The destination cache need not necessarily store the sought 
after web content data, but only maintain routing items that 
define where the web content data may ultimately be located 
through routing and ultimately stored among the cooperative 
caches. As such, the present invention solves the problem of 
maintaining cooperative cache forwarding and routing tables by 
broadcasting tri-ref erenced associated routing information. The 
tri-ref erenced associated routing information can then be used 
to create a forwarding and routing table in any arbitrary 
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distal cache, so as to migrate the forwarding and routing table 
information about the cooperative caches. This migration occurs 
without regard to load balancing, polling, frequency 
monitoring, or the mere transmission of URL requests from any- 
one cache to another cache as in Jordan. 

Applicant appreciates that many web features are found in 
various methods operating on various caches in cooperative 
systems, and that, the examination can become quickly confused 
if one is not careful to focus on the broadcasting steps of 
claim 1 in reference to any sole proximal cache, as in Jordan. 
Applicant was well aware of this potential problem. To make the 
examination process as focused and as convenient as 
practicable, claim 1 is directed only to the minimal novel 
broadcasting steps executed by a single lone proximal cache, so 
that, operational steps by any other lone cache, such as in 
Jordan, can be quickly compared for novelty. Does this prior 
art reference, Jordan, teach or suggest a single cooperative 
proximal cache executing these tri-referenced associated 
broadcasting steps? This determination is limited in scope to 
aid in the examination process. When viewing Jordan, a like 
reference perspective to a "proximal cache" serves to quickly 
clarify the comparison and highlight the points of novelties. 

That is, the examiner should compare apples to apples, and 
any lone cache in Jordan can be compared to the proximal cache 
of claim 1. However, because all of Jordan caches operate in 
like manner, any one cache in Jordan may be used for 
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comparison. In this regard, the migration and creation of 
forwarding and routing tables can be had through a unilateral 
tri -referenced associated broadcast communication from a 
broadcasting proximal cache as in claim 1. A distal cache can 
then use this broadcast communication for building a forwarding 
and routing table as recited in claims 19 and 20. As such, 
claim 1 and claim 19 highlight respective bifurcated functions 
for migrating forwarding and routing tables. Jordan relies on 
like caches whereas the proximal cache of claim 1 and the 
distal cache of claim 19 rely on a cooperation between 
differently operating caches, yet another clear distinction 
between Jordan and the present invention. 

Jordan teaches a load-balancing network of like cooperative 
caches that store web content data and maintain caching tables. 
Jordan does not solve the problem of migrating forwarding and 
routing tables about a network of caches. Jordan does not use 
the claim 1 solution of transmitting from a proximal cache to a 
destination cache tri-referenced routing information 
associating a URL-Id with a source IPA of an alternative source 
storing or pointing to where the URL- Id web content data may be 
sourced. In so doing, the invention of claim 1 serves to enable 
the migration of the forward and routing information about the 
cooperative distal caches that can then create forwarding and 
routing tables arbitrarily anywhere in the cooperative network. 

Jordan teaches that when a cache is overloaded by a URL 
request, the URL request is directed to another destination at 
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a destination IPA, so that the destination, that may store the 
web content data, can then function as a new alternative 
source. As such, the destination can retrieve the web content 
data, store it locally, and then respond to URL requests for 
the web content data so as to load share. As such, the 
destination and source are one in the same. Jordan does not 
solve the problem of migrating forwarding and routing tables 
among cooperative distal caches, or suggests the invented 
solution of broadcasting to a destination distal caches tri- 
referenced routing information associating URL-Id web content 
data and an alternative source of the web content data. 

In Jordan, a proximal cache at a proximal IPA receives a 
request for URL web content data from an originator or client 
browser. When the proximal cache at the proximal IPA is 
overloaded, the proximal IPA redirects the original request to 
a destination IPA also storing the web content data. The 
request is forwarded to an alternative source. The request 
contains an association between the requesting IPA and the URL- 
Id of the originator originally firstly storing the requested 
web content data. Then, the destination cache stores the web 
content data to serve URL-Id requests. The destination 
retrieves the URL- Id web content data, stores it locally, and 
updates its caching table indicating it has stored this URL web 
content data. Jordan teaches load sharing. Jordan does not 
teach a method of broadcasting tri-referenced routing 
information, including an association between URL-Id and an 
alternative source of the URL-Id web content data, but rather 
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directs the URL request to an unloaded server storing the 
sought after URL data. Jordan does not teach a method of 
broadcasting an association of a source with URL data to an 
arbitrary destination, that can then construct and maintain a 
routing and forwarding table. 

Jordan teaches a load-balancing web content data caching 
system that maintains a logical central directory for locating 
where requested web data is stored, preferably in the least 
loaded cache. (Col 7 lines 60-65). In Jordan, there is a 
guarantee that the owner indicated in the directory does store 
the sought after web content data. By contrast, the present 
invention makes no such guarantee, as the routing information 
merely provides a direction through which a request could be 
forwarded or routed until a destination cache is eventually 
reached that does store the sought after web content data 
specified in the URL request. The broadcasting provides the 
routing information and not the web content data. 

The present invention provides for the broadcasting of 
routing information from a proximal IPA. The routing 
information is a tri -referenced association between a proximal 
cache at a proximal IPA location, a destination cache at a 
destination IPA, and a source cache at a source IPA. The 
associated URL request for web content data originally provided 
at a URL IPA is an implied fourth location. The tri-ref erenced 
physical locations at the proximal IPA, source IPA, and 
destination IPA are particularly specifically stated in claim 
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1, while a fourth location of the original URL source location 
is also inferred. This specifically required tri-ref erenced 
association, as recited in claim 1, is essential to 
understanding the novelty of claim 1. This tri-ref erenced of a 
first proximal cache, a second distal destination cache, and a 
third distal alternative source cache is recited in claim 1. 
The URL and source IPA association in the routing information 
during broadcasting enables the building of a forwarding and 
routing table at the destination distal IPA. Jordan does not 
have this tri-ref erenced association or the capability of 
migrating forwarding and routing information through unilateral 
broadcasting. Jordan does maintain a caching table, which can 
be used to forward URL requests. However, the caching table is 
not maintained by virtue of receiving unilateral broadcast 
associated routing information. The caching table is not 
maintained by virtue of receiving unilateral broadcast routing 
information because, in Jordan, at least two of the claimed 
tri-referenced IPA locations, if not all three, are the same 
locations. In Jordan, the source and destination are one in the 
same, which receives a request, retrieved the URL data, updates 
its caching table, and becomes the alternative source, and 
hence, the limitation to only caching tables indicating exactly 
where is stored the requested web content data. 

In view of the abstract of Jordan, a "request" indicating a 
requester at a requester IPA and indicating the "object", that 
is the requested URL web content data, is "forward" directly to 
another cache, so that the "requests" are shifted, that is. 
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forward to another cache also storing the sought after web 
content data. Jordan does not use hopping or routing in any 
regard, as the examiner incorrectly suggests. Jordan merely 
forwards requests when overloaded. Jordan's shifting by 
forwarding requests perfects load balancing among caches. As 
such, Jordan maintains a directory as a correctly named caching 
table of all caches storing the sought after web content data 
for forwarding when overloaded. That is, all of Jordan's caches 
are merely source caches sharing loads by forwarding requests. 
There is a difference between a caching table and a forwarding 
and routing table. A caching table points directly to 
alternative source caches having the stored data. A forwarding 
and routing table points to another location that may or may 
not have the stored data, but ultimately indirectly points 
through routed hops to where the data may be ultimately found. 
When a proximal cache is overloaded in Jordan, the proximal 
cache sends the URL request, which is not routing information, 
to an alternate cache location, at an alternate destination. 
(See Figure 3) As such, each proximal cache monitors the 
frequency of the requests, and if overloaded, each proximal 
cache searches its caching table directory to find other caches 
storing the same web content data, and forwards the request to 
the alternate source cache. In this manner, load balancing and 
web content data sharing is achieved. 

Jordan forwards a URL request to a destination source 
cache, being both a destination and a source. Each cache in 
Jordan is a proximal cache, a destination cache, and ultimately 
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a source cache, each maintaining a respective like caching 
table. The communicated URL requests or polling inquiries are 
simply not routing items having a tri-ref erenced association 
between a proximal cache, a destination cache, and a source 
cache. The polling in Jordan is a bilateral communication, and 
not a unilateral communication. Jordan does not communicate 
from one proximal cache to a destination cache indicating that 
data is available through, but not necessarily at, yet another 
source cache. Jordan's caches do inquire through multicast 
polling where the information is stored for maintaining the 
caching table. When stored at the destination, the proximal 
overloaded cache sends the URL request to the destination to 
load share. In Jordan, there is no tri-ref erenced associated 
routing information broadcast from a first proximal cache to a 
second destination cache indicating a direct forwarding or 
indirect routing path to where the web data is stored on a 
third source cache . In Jordan, there is no routing information 
whatsoever, but rather, mere requests to send web content data 
to a requester or polling inquiries. In Jordan, an overloaded 
proximal cache searches its caching table directory, and then 
communicates and forwards the request from a proximal cache to 
a distal destination also serving as an alternative source 
cache. As such, Jordan does imply operation among three 
locations including a requester, an overloaded cache, and an 
underloaded cache. The operation in total does involve three 
locations, a requester, a proximal cache, and a destination 
source cache. However, the information consists of mere 
requests, inquiries, and does not point directly or indirectly 
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to yet another third alternative source cache of the web 
content data. In Jordan, the destination and source are one in 
the same. The requests may be also used as the inquiries as to 
whether or not the web content data is stored at a distal 
cache. Hence, Jordan's communicated information is different. 
For maintaining the caching table, Jordan's information may 
include URL requests, the requester, and the destination. The 
polling inquires would not include the alternative source as 
with the tri -referenced associated routing information of claim 
1. Jordan provides for mere URL requests or inquiries, whereas 
the present invention broadcasts actual tri-ref erenced routing 
information. The information is different, and hence, Jordan 
does not anticipate, and information communicated ultimately 
serves different purposes, such as load sharing using caching 
tables as opposed to routing information migration, and hence, 
the arguments as to nonobviousness . Jordan solves the problem 
of load balancing using forward requests, polling inquires, and 
caching tables whereas the present invention solves the problem 
of migrating routing tables and does so by broadcasting tri- 
ref erenced associated routing information. With different 
problems solved, different objectives, and different solutions, 
Jordan does not remotely suggest the present invention. 

Specifically comparing apples to apples, Jordan teaches 
multicasting where a cooperative cache multicast URL requests 
or inquiries to other caches. (Col 8 line 1) These URL 
requests may function as simple inquiries, such as, "do you 
have this information", and the answer may be yes indicated by 
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merely sending the web content data in response. In so doing, 
each cache polls the remaining caches to maintain the caching 
tables. Jordan maintains a caching table by polling caches 
through bilateral bi-ref erenced communications. The present 
invention broadcasts unilateral tri-ref erenced routing 
information, so that, distal caches can maintain routing and 
forwarding tables. Jordan bilaterally multicasts bi-ref erenced 
unassociated inquires to maintain caching tables in proximal 
caches. The present invention unilaterally broadcasts tri- 
ref erenced associated routing information for maintaining 
forward and routing tables in distal caches. The two processes 
are completely different serving different objectives for 
solving different problems. 

Jordan is clear and teaches load balancing. "Direct 
requests 155 are sent from the clients ... to cache server". 
(Col 5 line 55) "If an actual load imbalance is identified ... 
the load monitor initiates a shifting of forwarded requests 
from the overloaded cache to ... less loaded servers". (Col 6 
line 3) "if the owner is currently overloaded ... the load 
monitor finds an underloaded cache . . . and assign it as the new 
owner of the requested object". (Col 6 line 63) "The ownership 
information for the object in the caching table is updated". 
(Col 6 line 64) . "The request can be forward ... to the new 
owner". (Col 7 line 3) 

The examination states that Jordan's request includes 
source address, destination address, forwarding address, next 
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hop address, as disclosed in the request to an arbitrary cache 
or destination upon a cache miss wherein the new entry is 
created for the object in the caching table a routing or 
forwarding table (Col 6 L50-67, and Fig 2a) . 



Is that really so? A search of specification reveals that 
the term "HOP" is not found at all. A search of the summary and 
preferred embodiment reveals that the term "route" is not used 
at all. Yet, to the examiner, it is apparently clear from these 
apparent phantom words. This is truly remarkable. Within this 
cited text, none of these terms are mentioned at all, yet, this 
section is cited as the basis of the rejection. This is also 
equally remarkable. Applicant appreciates that the technology 
is complex and involves many caches at many different locations 
serving different uses while communicating different types of 
information. Nonetheless, precise and careful reading is 
required to fully understand the differences between Jordan and 
the present invention. 

The caching table shown in Fig 2a of Jordan includes 
objects (the URL) and "Ownership" that is, the caches A, B, C 
storing the web content data. Such specific A, B, and C caches 
are not arbitrary, as indicated by the examiner, but indicate 
exactly where the data can be found and exactly where the 
request can be forwarded for load balancing and sharing. It 
appears the examiner reads more in Jordan than what is really 
there . 
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The plain full text does not read as the examiner 
indicates. "FIG. 3 shows an example of a logic flow for steps 
taken by the load monitor 120 in response to a request 125 from 
a cache server 150 because of a cache miss. As depicted, in 
step 201, it checks to see if the requested object /partition 
can be found in the caching table. If not, in step, 202, a new 
entry is created for the object /part it ion and a cache server is 
assigned as its owner. After the entry is located in the 
caching table, in step 203, the forwarding frequency 1011 is 
updated, e.g., incremented by 1. The load monitor then examines 
the load table 102 to see if the owner is currently overloaded 
(and that the forwarding frequency 1011 is a significant 
contributor thereto), in step 204. If yes, in step 205, the 
load monitor finds an underloaded (or less loaded) cache server 
and assign it as the new 10122 (or shared) owner 10122 of the 
requested object. The ownership information 1012 for the object 
in the caching table 101 is updated accordingly. Those skilled 
in the art will appreciate that the logic flow could comprise a 
shared 10123 or hierarchical ownership 1012 in the caching 
table 101 or other data structure employed. The request 
(possibly with a copy of the requested object) can then be 
forwarded 125 to a new sole 10122 (or shared 10123) owner, in 
step 206. Alternatively, the new owner can be requested to 
obtain 115 an object copy from the originating object server, 
e.g., via the Internet 110." (Col 6 lines 50-66). 

As such, the examiner incorrectly cites a specific section 
of text standing for the proposition that "On the other hand. 
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Jordan, in its clear context, explicitly teaches the process of 
transmitting routing information, (such as source address, 
destination address, forwarding address, next hop address, as 
disclosed in the request) to an arbitrary cache or destination 
upon a cache miss, wherein the new entry is created for the 
object in a caching table, or routing or forwarding table." In 
discussing Jordan, "in its clear context", the examiner uses 
the terms such as "source address", "destination address", 
"forwarding address", "forwarding table", yet a simple cursory 
examination of the cited text upon which the examiner relies, 
teaches no such things nor uses any of these terms. Where are 
these terms in the cited text? How possibly could one make this 
apparent leap, but through some kind of tortured reasoning? 
These terms used by the examiner are not in the cited text, nor 
suggested in any clear regard, yet asserted by the examiner, as 
"clear". The record of the present prosecution is becoming so 
distorted by the examiner's unsupported assertions, that this 
record is quickly becoming, in and of itself, a strong 
indicator of nonobviousness. 

Jordan should be viewed from the exclusive perspective of 
a lone proximal cache, as dictated by the structure of claim 1 
of the present invention. Jordan multicasts different 
information, that may be simple URL requests indicating a 
requester and the URL to a source of the URL data. This is 
opposed to broadcasting routing information associating an 
alternative source and a URL, which does not even request the 
URL data. In Jordan, the URL request is communicated to a 
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different location, that is, directly to a source of URL web 
content data for retrieving the URL content data. This is 
opposed to communicating to a destination cache that merely 
receives the routing information indicating an alternative 
source, which communication can then be used to build a 
forwarding and routing table. Jordan solves a different problem 
that is one of load balancing among like caches. This is 
opposed to solving the problem of migrating routing information 
for the purpose of building routing and forwarding tables in 
different arbitrary distal caches. With all kind due respect, 
Jordan does not remotely suggest the prevent invention. 

Claim 1 is patentable over Jordan and in combination with 
other references. However, the examiner seems to indicate a 
desirability of including claim language directed to building a 
forwarding and routing table at the destination cache. Yet, a 
claim covering the broadcasting by one proximal cache and the 
forwarding table building by another destination cache renders 
patent enforcement problematic, because different manufacturers 
could independently build the two differently operating caches. 
To provide clear notice to potential infringers, independent 
claims 1 and 8 cover the necessary broadcasting process while 
new claims 19 and 20 cover the subsequent building of the 
forwarding and routing tables in the destination caches using 
the broadcast routing information. 



/// 
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Jordan multicasts polling bi -referenced inquiries from a 
proximal cache to destination caches that affirmatively respond 
in bilateral communications for maintaining a caching table in 
the proximal cache , which caching table is then used for 
forwarding URL requests to those destinations storing the URL 
data when a URL request frequency at the proximal cache is high 
for load balancing. 



The present invention of claim 1 broadcasts from the 
proximal cache to destination caches tri-ref erenced routing 
information in a unilateral broadcast communication, where the 
routing information associates a source IPA with stored URL 
data or stored additional routing information to a source of 
stored URL data, so as to enable the maintenance of forwarding 
and routing tables in the destination caches as in claims 19 
and 20. 



/// 
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Jordan relies on like caches all with like caching tables 
and with like frequency monitoring, whereas the proximal cache 
of claim 1 and the distal cache of claims 19 or 20 rely on a 
cooperation between differently operating types of caches. 
Jordan does not suggest such a bifurcated cache function. The 
present invention is not required to poll other caches. The 
present invention does not require load monitoring. The present 
invention does not require multicast bilateral communications. 
The present invention does not maintain limited caching tables 
restricted to a few caches for simple load sharing only among 
them through forwarding URL requests. The present invention 
enables the building of generalized routing and forwarding 
tables in arbitrary distal caches regardless of what web data 
is stored on the distal destination caches. The present 
invention enables cooperative caching about a network of 
cooperative caches without regard to the frequency of URL 
requests at any one cache. Jordan does not have these benefits. 
The alternative distal source cache may store and source the 
URL web content data through directed forwarding requests or 
the alternative distal source cache may indirectly point 
through hop routing to yet another more remote distal 
alternative source cache storing the URL web content data, as 
indicating the equivalence between forwarding and routing, 
enabling any number of routing hops to locate the sought after 
web content data stored in any one of any number cooperative 
caches disposed anywhere within a network. The present 
invention is a significant advancement in the art and enables a 
comprehensive generalized network-wide caching solution. 
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The cited references do not teach or remotely suggest 
broadcasting of tri -referenced associated routing information 
from a FIRST proximal cache to a SECOND destination distal 
cache, with the routing information associating URL web content 
data with a THIRD alternative distal source cache. Such 
broadcasting of this specific tri-ref erenced associated routing 
information then enables the maintenance of forwarding and 
routing tables in arbitrary destination caches for forwarding 
and routing URL requests about a network of cooperative caches. 
Allowance of the claims is requested. 



Derrick Michael Reid, Esq. 
The Aerospace Corporation 
PO Box 92957 Ml/040 
Los Angeles, Ca 90009-2957 
Reg. No. 32,096 



Respectfully Submitted 
Derrick Michael Reid 
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